Pardon me if this is a duplicate...I didn't get my first post back. Hmmm, I have a few questions/comments about all of this... > No one has actually discussed the implications of the GUI running on the > firewall and what dangers it may represent, if any? Exactly, I'd like to hear/read anyone's comments on this. > Have all the listening ports been plugged? ^^^^ ^^^ ^^^ ^^^^^^^^^ ^^^^^ ^^^^ ^^^^^^^ Can some who "own/drive/smoke's one" please answer this? > Do they export the GUI front end to client machines? ^^ ^^^^ ^^^^^^ ^^^ ^^^ ^^^^^ ^^^ ^^ ^^^^^^ ^^^^^^^^ Again, can some who "own/drive/smoke's one" please answer this one too? > I won't pretend to be an experienced cracker, but I have heard > that X has many security implications to consider - can anyone > expand on this? I won't pretend either but having "played around"... X11R5 defines, and the way I see the MIT releases implemented, are two mechanisms that can be used for secure access control. XDM-AUTHORIZATION-1, which is similiar to the MAGIC-COOKIE stuff, but uses DES encryption to encrypt the authorization data that is passed between client and server. Now, to compile that scheme you need an implementation of DES in the file: /mit/Xdmcp/Wraphelp.c Due to U.S. export regulations, I certainly hope this wasn't in the SunOS distribution to Israel. If this was developed in Israel, please explain how FireWall-1 dealt with this? I can only assume they used SUN-DES-1, and this is based on the public key Sun Secure RPC system included with the SunOS releases. Most servers also use a host access list file (/etc/X.hosts or equivalent if it is a UNIX based box) to determine whether to grant access. If the client is running on a host that is on the server's host access list, the connection is granted (even if the authorization data is wrong!). The host access list will be empty if an authorization mechanism is in use. Now, as far as I am aware "X" DOES NOT provide any protection from unauthorized access to individual windows, pixmaps, or other obsenities, once a connection has been made. Let me demonstrate... If I'm a cracker and I write a program that gets or even guesses a windows ID that my program didn't create, using a querytree request you can manipulate or destroy the window. One of the oldest tricks is... cat /dev/fb > [filename]; xloadimage -onroot FULL [filename] here, you would have succesfully grabbed whatever was on the screen of that Sun classic and wrote it to a file that you could redisplay for yourself. Of course, this assumes that the SysAdmin didn't change the fb privleges, if so, well I guess the cracker would have to obtain root permission first. > Interesting. If Firewall-1 gets a patent, I may be able to > show prior art. Can Firewall-1 get a patent in the U.S.A. w/o breaching anyone else's work? > Again, we are talking about this RUNNING on the firewall. Looking at > it from the cracker perspective, what would be a weakness to exploit if > a firewall was known to be running X? Perhaps forge X packets and run > a "lookalike" of the GUI for the unsuspecting admin to type away at? Well, I hope what I tried to depict above serves as a weakness that one may try to exploit. At any rate, enough of this...can anyone help me out with the prior questions? Thanx, I'm also lost, can you direct me to the information superhighway? ______________________________________________________________________ /// / /// Stephen E. Gaul, Jr. / /// /\ Air Products and Chemicals, Inc. / __/// /__\ Lehigh Valley, PA 18001 / ///_ ______ __ INET: gaulse@ttown.apci.com || gaulS@moravian.edu / ///// /______\ \/ VOICE: (215) 481-7054 / ///______________ FAX: (215) 481-3988 / //////////////////____________________________________________________/ NOTE: These statements and opinions are mine, not those of APCI...